The invention relates to the general field of exchanging data via the Internet, and it relates more particularly to communications between remote applications via access gateways.
In known manner, an access gateway enables a plurality of terminals in a given local network to communicate with remote networks, and to do so via the Internet, for example.
FIG. 1 shows an example in which a first terminal 2A included in a local network LAN_A can communicate with a remote server 2B situated in a remote local network LAN_B. To do this, a first gateway 6A is placed in series between the terminal 2A and the Internet, and the second gateway 6B is placed in series between the server 2B and the Internet. In this way, an application client 4A implemented in the terminal 2A can communicate with a remote application 4B situated in the server 2B. In this example, consideration is given to a web browser implemented in the terminal 2A and seeking to communicate with a web server implemented in the server 2B.
In general, each piece of equipment connected directly to the Internet (such as the gateways 6A and 6B, for example) must be identified by an IP address referred to as a “public address” in order to be able to communicate with other pieces of equipment on the Internet. By way of example, such an address is allocated on registering with a DHCP server (i.e. a server that allocates IP addresses using the dynamic host configuration protocol). A public IP address is said to be “routable” over the Internet, i.e. that it can be used to identify the source or the destination of a data packet transferred via the Internet.
Furthermore, each piece of host equipment in a local network (such as the terminal 2A or the server 2B) must be identified by means of an IP address known as a “private address” or a “local address”, with this address being specific to the local network in question. A local IP address may be allocated to only one piece of equipment within a given local network, thereby enabling a gateway to identify the pieces of equipment with which it communicates in its local network. A local address is not routable over the Internet, which means that it cannot be used outside the local network under consideration.
At present, the number of public IP addresses allocated to a given gateway is frequently less than the number of pieces of equipment (terminals, servers, . . . ) present in the local network of the gateway. The gateway then implements a network address translation (NAT) function that consists in storing correspondences between local IP addresses and public IP addresses in pairs in a table in the form (local address, public address). The gateway is thus capable of dynamically assigning the public addresses it has available to the pieces of equipment in its own local network seeking to communicate at any given instant outside the local network.
In addition, the NAT function frequently updates the user datagram protocol (UDP) or transmission control protocol (TCP) ports of the communications sessions of pieces of equipment in order to be parsimonious in the use of the public address (or addresses) allocated to the gateway. The NAT function is then a so-called network address port translation (NAPT) function that consists in storing the correspondences between local and public IP addresses, and also the corresponding public and private ports. Each correspondence is then stored in a table as an entry having the form (local address, local port, public address, public port). In the present document, the term “NAPT” is referred to more simply by using the term “NAT”.
Thus, the gateways 6A and 6B update their respective NAT tables 8A and 8B as soon as they obtain new assignments of public addresses and associated ports.
Furthermore, at present, the Internet protocol that is in the most widespread use for implementing IP addresses is known by the acronym IPv4 (for Internet protocol version 4). This IP protocol version serves to allocate so-called “IPv4” IP addresses that are encoded on four 8-bit bytes, which corresponds to 32-bit coding. In general, an IPv4 address is written in the form of four decimal numbers separated by dots, e.g. such as 193.43.55.67.
Unfortunately, it is generally accepted by the community of IP connectivity service providers that it is inevitable that available public IPv4 addresses will become exhausted. Encoding IPv4 addresses on 32 bits limits the number of potential IPv4 addresses to 232 (i.e. 4,294,967,296), and thus limits the subset of distinct public addresses that can be allocated within the Internet by the appropriate authorities (e.g. the Internet assigned numbers Authority (IANA)). Initial shortages of public IPv4 addresses are predicted for early 2011.
This outlook has led operators to plan solutions for mitigating this shortage. Thus, in order to overcome the limitation associated with 32-bit coding of IPv4 addresses in the long run, operators are progressively putting into place a new IP protocol version known by the acronym IPv6 (Internet protocol version 6). This new protocol enables IP addresses to be encoded on 128 bits (giving 2128 potential distinct IP addresses), thereby providing an address space that is much larger. Nevertheless, a certain amount of time is going to be necessary to enable the new protocol to be implemented and harmonized throughout the Internet.
In parallel with IPv6 deployments, one of the transitional solutions consists in enabling public IPv4 addresses to be shared between a plurality of Internet clients. In this way, a plurality of clients (gateways, etc.) may be connected to the Internet while using a single public IPv4 address in common, referred to as a “shared” address.
Below in this document, the term “address” or “IP address” is used to refer to an IPv4 address.
At present, certain systems already enable shared IPv4 addresses to be managed on the Internet. One solution commonly known as a “port range” has been developed in particular to deal with the shortage of IPv4 addresses. That solution consists in allocating to an Internet access gateway:                a shared public IPv4 address; and        a fixed range of authorized source ports.        
The operating principle of the port range method is described below with reference of the access gateway 6A shown in FIG. 1.
In the port range method, the gateway 6A has allocated thereto a public IPv4 address that is written AdresPub, together with an authorized port range PortRange_A, e.g. arranged going from port 1024 to port 2047. The public address AdresPub is a shared address that can be assigned to other gateways, such as the gateway 6B, for example, providing the associated port range PortRange_B is completely disjoint from the range PortRange_A.
Furthermore, the gateway 6A implements a NAT function: on receiving an IP data packet from the terminal 2A destined for the terminal 2B and specifying as its source the private address of the terminal 2A and the source port associated with the application 4A, the gateway 6A replaces the source address of the packet by the public address AdresPub and, if necessary, it modifies the source port so as to make it lie in the range PortRange_A.
Furthermore, when a data packet is sent from the Internet to the gateway 6A, a specific piece of Internet equipment known as a port range router (PRR) (not shown in FIG. 1) is capable of determining the gateway to which the packet is to be sent, with this being based on the destination IPv4 address and on the destination port included in the packet in question. The PPR then steers the packet in transit towards the appropriate destination gateway and it does so without modifying the packet in question. For example, if the PRR determines that the destination address of the packet is AdresPub and that the destination port of the same packet lies in the range PortRange_A, it directs the packet towards the gateway 6A.
It should be observed that the application field of the port range method is not limited to Internet access gateways, but may be applied to other pieces of equipment, such as mobile terminals, for example.
The port range method is described in particular in the following documents: WO 2009/125158A2, WO 2010/004156A1, and WO 2010/004180A1.
Nevertheless, the port range method presents drawbacks for certain uses.
For example, if the gateway 6B implements the port range method, then the web browser 4A on the terminal 2A will in general be unable to access the web server 4B hosted in the server 2B. In order to access the web server, the web browser must send IP data packets to the gateway 6B that include the destination public address and the destination public port that are associated with the web server 4B in the NAT entries 8B. A web server is so called “well-known” application that is accessible by default on private port 80 (hypertext transfer protocol (HTTP)). Unfortunately, since the gateway 6B is implementing the port range function, in its NAT table 8B it has an entry that associates the private port 80 with a given public port PubPort_Server that lies in the range PortRange_B. In general, the web browser 4A has no knowledge of the public port PubPort_Server assigned by the gateway 6B to the web server 4B, and it therefore has no access thereto.
It is therefore necessary for the web server 4B to communicate its public port PubPort_Server to all of its potential application clients, and in particular to the web browser 4A. Various techniques enable an application client such as the web browser 4A to determine PubPort_Server. By way of example, the web browser 4B may install an HTTP tag containing the value of PubPort_Server in a web page of another server on the Internet. However that practice is constraining and not very common. Furthermore, for applications other than a web server, it is not possible to envisage using the HTTP tag technique. Another technique consists in previously informing the domain name servers (DNSs) 10 of the value of PubPort_Server assigned by the gateway 6B to the web server 4B. This function known under the acronym SRV (for service record) is a DNS option that makes it possible in a DNS server to store a port corresponding to a service in association with an IP address. It is thus possible in the DNS server 10 to store the public port number to be used for accessing a remote application in association with the public IP address of the corresponding gateway. By way of example, this information may be stored in a table 12 included in the DNS server 10. By way of example, the web browser 4A may send a request via its gateway 6A to the DNS server 10 and in response it may receive the destination IP address of the web server 4B together with the associated public port PubPort_Server.
Nevertheless, the use of the SRV method in the context of the port range solution is unsatisfactory since numerous application clients (such as most web browsers), are, at present, incapable of making use of the SRV function.
There therefore exists at present a need for a solution that makes it possible to use a public address that is shared among a plurality of port ranges, and for this to be possible without the limitations and drawbacks that are inherent to the conventional port range solution. More precisely, there exists a need for a version of the port range solution that is improved in such a manner that remote applications can communicate with one another via the Internet even though they do not know the public ports of the other parties.